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Name Type Fields 
Abstract 
SEcure Neighbor Discovery (SEND) defines the Name Type field in the 
ICMPv6 Trust Anchor option. This document specifies new Name Type 
fields based on certificate Subject Key Identifiers (SKIs). 
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1. Introduction 


SEcure Neighbor Discovery (SEND) [RFC3971] utilizes X.509v3 
certificates that include the [RFC3779] extension for IPv6 addresses 
to certify a router's authority over an IPv6 prefix for the NDP 


(Neighbor Discovery Protocol). The Trust Anchor (TA) option in 
Section 6.4.3 of [RFC3971] allows the identification of the Trust 
Anchor selected by the host. In that same section, two name types 


were defined: the DER Encoded X.501 Name and a Fully Qualified Domain 
Name (FQDN). 


In any Public Key Infrastructure, the subject name of a certificate 
is only unique within each Certification Authority (CA). 
Consequently, a new option to identify TAs across CAs is needed. 


In [RFC6494], the certificate profile described in [RFC6487] is 
adopted for SEND. In these documents, the Subject field in the 
certificates is declared to be meaningless and the subjectAltName 
field is not allowed. On the other hand, the Subject Key Identifier 
(SKI) extension for the X.509 certificates is defined as mandatory 
and non-critical. 


This document specifies new Name Type fields in the SEND TA option 

that allows the use of the SKI X.509 extension to identify TA X.509 
certificates. This document also defines experimental and reserved 
Name Types values. 


Finally, this document updates [RFC3971] by changing the "Trust 
Anchor option (Type 15) Name Type field" registration procedures from 
Standards Action to Standards Action or IESG Approval [RFC5226]. 


2. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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3. Name Type Fields in the ICMPv6é TA Option Defined in This Document 


The following Name Type fields in the ICMPv6 TA option are defined: 


Name Type Description 
0 Reserved 
3 SHA-1 Subject Key Identifier (SKI) 
4 SHA-224 Subject Key Identifier (SKI) 
5 SHA-256 Subject Key Identifier (SKI) 
6 SHA-384 Subject Key Identifier (SKI) 
7 SHA-512 Subject Key Identifier (SKI) 
253-254 Experimental 
25:5 Reserved 


Name Type field values 0 and 255 are marked as reserved. This means 
that they are not available for allocation. 


When the Name Type field is set to 3, the Name Type field contains a 
160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string 
of the subject public key, as described in Section 4.8.2 of 
[RFC6487]. Implementations MAY support SHA-1 SKI name type. 


When the Name Type field is set to 4, 5, 6, or 7, the hash function 
will respectively be: SHA-224, SHA-256, SHA-384, or SHA-512. 
Implementations MAY support SHA-224, SHA-256, SHA-384, and SHA-512 
SKI name types. 


Name Type fields 253 and 254 are marked as experimental, per guidance 
in [RFC3692]. 


4. Processing Rules for Routers 


As specified in [RFC3971], a TA is identified by the SEND TA option. 
If the TA option is represented as a SKI, then the SKI MUST be equal 
to the X.509 SKI extension in the trust anchor’s certificate. The 
router SHOULD include the TA option(s) in the advertisement for which 
the certification path was found. Also, following the specification 
defined in [RFC3971], if the router is unable to find a path to the 
requested anchor, it SHOULD send an advertisement without any 
certificate. In this case, the router SHOULD include the TA options 
that were solicited. 
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5. IANA Considerations 


IANA has updated the "Trust Anchor option (Type 15) Name Type field" 
registry to include the following values: 


+--------- fa EE E E EE D OE A + 
| Value | Description | 
+--------- R a nn a A A + 
0 Reserved (Section 3) 
3 SHA-1 Subject Key Identifier (SKI) (Section 3) 
| 4 | SHA-224 Subject Key Identifier (SKI) (Section 3) | 
| 5 | SHA-256 Subject Key Identifier (SKI) (Section 3) | 
| 6 | SHA-384 Subject Key Identifier (SKI) (Section 3) | 
ieee: | SHA-512 Subject Key Identifier (SKI) (Section 3) | 
| 253-254 | Experimental Use (Section 3) 
| 255 | Reserved (Section 3) 
+--------- Fn nn E EE ES + 


Table 1: New Name Type Field Values in the ICMPv6 TA Option 


IANA has also modified the registration procedures for the "Trust 
Anchor option (Type 15) Name Type field" registry to Standards Action 
or IESG Approval [RFC5226]. 


6. Security Considerations 


The hash functions referenced in this document to calculate the SKI 
have reasonable random properties in order to provide reasonably 
unique identifiers. Two identical identifiers in the same validation 
path will cause the router to stop fetching certificates once the 
first certificate has been fetched. In the case that the upward 
certificate was configured as a TA by a host, the router will send to 
this host an incomplete list of certificates, causing the SEND 
validation to fail. 


For experimental values of the Name Type field, the guidance given in 
[RFC3692] about the use of experimental values needs to be followed. 
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